大模型能读 1M Token，就真的读懂了吗？

来源：htmlDecode("悟鸣AI")

原文链接：https://mp.weixin.qq.com/s/ImkyALC_vWUaiTZIFgRmxw

---

这是悟鸣的第 260 篇公众号文章。
大家好，我是悟鸣。
现在很多人选大模型，第一眼会看上下文长度。
32K、128K、200K、1M……
数字越大，看起来越厉害。好像只要窗口足够长，一本书、几百页 PDF、一整个代码仓库，甚至一堆聊天记录，都可以直接丢进去。
但这里有个问题：模型没有报错，正常给你回答，只能说明它把这些内容“收下了”。
它有没有真的找到关键证据？有没有被无关信息带偏？有没有漏掉中间某个细节？有没有干脆凭自己的记忆在回答？
这些才是我们真正应该关心的。
最近我重新读了 NVIDIA 的一篇论文：
RULER: What's the Real Context Size of Your Long-Context Language Models?
直译过来就是：你的长上下文语言模型，真实上下文大小到底是多少？
这篇论文提出了一个叫 RULER 的评测框架。我觉得它最有价值的地方，其实不在于给模型重新排榜，重点在于提醒我们：
看长上下文能力，不能只看厂商写在参数表里的窗口大小，也不能只靠“大海捞针”判断模型好不好。
换句话说，长上下文的关键点可以压成一句话：别只看能塞多少，要看塞进去以后能不能用好。

1. “大海捞针”为什么不够了？

长上下文评测里有一个经典测试，叫 Needle-in-a-Haystack，简称 NIAH。
说人话，就是“大海捞针”。
做法不复杂：把一句关键信息藏进一大段文本里，然后问模型能不能找出来。
比如在一堆无关文字里塞一句：
long-context 的特殊魔法数字是 12345。
然后问：
long-context 的特殊魔法数字是多少？
模型答出 12345，就算通过。
这个测试当然有价值。至少它能看出模型在长文本里有没有基本的定位能力。
但我们平时用大模型，很少只是为了找一个孤零零的数字。
更常见的情况是： 从多份材料里找证据； 判断人物、事件和结论之间的关系； 从一堆用户反馈里归纳高频问题； 在很多干扰材料里回答一个需要理解上下文的问题； 从会议纪要、合同、需求文档里列出所有待办或风险项。
这些任务都比“找 12345”复杂。
NIAH 主要测的是检索能力。长上下文真正麻烦的地方在于，模型不仅要“看见”，还要能把看到的内容稳定用起来。

2. RULER 到底测了什么？

RULER 用的是合成 benchmark，不是传统的真实文章问答数据集。
“合成”在这里不是缺点。真实数据往往太复杂，模型可能靠训练阶段见过的知识回答，也可能被题目格式影响。合成任务的好处，是可以更干净地控制上下文长度、干扰信息和任务难度。
论文主要把长上下文能力拆成了几类。
第一类是检索。
它不只测最简单的 NIAH，而是把“针”变得更接近真实场景： 可能是一个 key-value； 可能是多个 key； 可能一个 key 对应多个 value； 也可能一次问多个 query； value 既可能是数字、单词，也可能是 UUID 这种更长、更容易抄错的字符串。
这就比“找 12345”难很多。真实文档里也常常不是只有一个答案，旁边还会有很多长得很像的干扰项。
第二类是多跳追踪。
论文里设计了一个 Variable Tracking 任务，大概长这样：
VAR X1 = 12345
VAR X2 = X1
VAR X3 = X2
然后问模型：哪些变量最终指向 12345？
看起来像编程题，本质上是在测模型能不能在长上下文里追踪关系链。
放到真实使用里，就像你让 AI 读一堆项目文档，判断某个需求是谁提出的，中间经历了哪些变更，最后影响到哪个模块。
第三类是聚合。
比如给模型一长串词，让它找出出现次数最多的词。
这时任务已经从定位某一句话，变成了在长上下文里统计、汇总。会议纪要总结、用户反馈归因、评论里提炼高频问题，都有类似影子。
第四类是问答。
作者把 SQuAD、HotpotQA 这类短文本问答任务扩展成长上下文场景：把包含答案的段落插入大量干扰段落里，再让模型回答问题。
这样一来，模型不仅要找到相关段落，还要理解问题，并且不能被旁边的干扰材料带跑。
所以 RULER 的思路其实很直接：
别只问模型能不能找到一根针。还要看它能不能在一大堆材料里检索、追踪、聚合、问答，并且尽量找全答案。

3. 标称长度和有效长度，中间差得不小

论文主实验评测了 17 个长上下文模型，包括 Gemini-1.5-Pro、GPT-4 和 15 个开源模型。
评测长度从 4K、8K、16K、32K、64K，一直到 128K。每个任务、每个长度生成 500 个样本。
作者还定义了一个“有效上下文长度”。
它的判断方式是：用 Llama2-7B 在 4K 上的表现，也就是 85.6%，作为阈值。如果某个模型在某个长度上超过这个阈值，就认为它在这个长度下表现还算满意。模型能通过的最大长度，就是它的 effective length。
这个定义当然不是唯一标准，但很直观。
它问的是：
你标称支持 128K，那到了 128K，表现还能不能维持在一个基本可用的水平？
结果不算乐观。
论文摘要里有个很关键的结论：被测模型都声称支持 32K 或更长上下文，但只有大约一半能在 32K 长度维持满意表现。
更刺眼的是，几乎所有模型在达到自己标称上下文长度之前，表现就已经跌破阈值。
论文表 3 里有几个例子： Gemini-1.5-Pro 标称 1M，在 4K 到 128K 上平均分 95.8，有效长度超过 128K； GPT-4 标称 128K，论文里的有效长度是 64K； Yi-34B 标称 200K，论文里的有效长度是 32K； 一些标称 32K 的模型，有效长度甚至低于 4K。
这里要特别补一句事实边界。
RULER 是 2024 年的论文，GitHub 仓库后来也补充了 Jamba-1.5、Qwen2.5/Qwen3、EXAONE 等更新模型结果。所以这些例子更适合用来理解“有效上下文”这个概念，不适合当成 2026 年最新模型排行榜来看。
新的模型还会不断出现，没必要死记谁排第几。
真正值得记住的是这个判断：上下文窗口是模型“最多能接收多少”，有效上下文才是模型“能稳定用好多少”。

4. 长上下文里，模型通常怎么出错？

论文还专门分析了 Yi-34B-200K 在更长输入和更复杂任务下的表现。
这些错误很有参考价值，因为我们日常用 AI 时也经常碰到类似情况。

第一种：看到了，但没找准

在简单 NIAH 任务里，模型可能接近满分。
但当“针”的类型变复杂，比如从数字变成 UUID，或者周围出现大量相似干扰项，错误就会变多。
论文提到，在很长的输入下，Yi 有时不能完整返回 32 位 UUID。
这说明模型不一定完全没看到。更可能是定位和复制精度不够。
我们让模型从长合同里抽合同编号、订单号、表格字段时，也会遇到这种问题：它大概知道答案在哪，但细节抄错了。

第二种：被干扰信息带偏

当上下文里塞进更多“假针”，模型表现会下降。
极端情况下，整个 haystack 都充满干扰 needle。论文里，Yi 在 256K 时大约下降了 40 个百分点。
这对 RAG 和知识库问答尤其有提醒意义。
很多人以为资料塞得越多，模型就越聪明。但资料越多，干扰也越多。
如果检索、分块、排序和上下文组织做得不好，模型未必更聪明，反而更容易被噪声拖走。

第三种：多答案召回不全

有些任务要找一组答案，不是单个答案。
比如一个 key 对应多个 value，或者一次问多个 query。论文发现，模型在这类场景下容易返回重复答案，也容易漏掉一部分答案。
这太常见了。
你让模型“列出这份会议纪要里的所有待办事项”，它可能列出大部分，但漏掉一两个藏在中间的小项。
如果只是写总结，问题可能不大。
可如果场景换成合规审查、合同风险、医学材料、财务报表，“漏一项”就很麻烦。

第四种：复制上下文，或者凭记忆回答

RULER 里还有一个有意思的现象：上下文变长后，模型有时会更倾向于复制上下文里的片段。
在 Common Words Extraction 任务里，Yi 在 128K 时超过 80% 的输出，只是在复制前面 one-shot example 里的字符串。
另一类错误正好相反：模型不再认真使用上下文，而是调用自己的参数知识来回答。
比如在词频统计任务里，有模型会输出 “the”“an”“a” 这类常见英语词，而不是去数上下文里真正出现最多的合成词。
这两种错误我们平时都见过。
一种是机械复制，看起来像引用了材料，其实没完成任务。另一种是自信发挥，语言很顺，但和你给的材料关系不大。
长上下文麻烦就麻烦在这里：它不一定明显报错，而是用一种很像正确答案的方式出错。

5. 普通用户可以怎么用这篇论文？

我读完 RULER 最大的感受是：不要把长上下文当成万能收纳箱。
现在很多 AI 产品都在强调“大上下文”“长记忆”“一次读完几百页 PDF”。这当然是进步。
但真要把 AI 放进工作流里，尤其是知识库、代码库、合同、论文、会议纪要这些场景，光看窗口大小不够。

1. 能少塞就少塞，先提高上下文质量

很多时候，有价值的资料并不等于把所有材料都塞进去。更好的做法，是把最相关、最干净、结构最清楚的资料放进去。
长上下文当然有用。但上下文越长，噪声管理越重要。
如果你给模型的是一堆重复、过时、互相冲突、格式混乱的材料，模型不会自动变成专家。
它更像是被材料淹没的新人：手里东西很多，但未必知道该看哪一页。

2. 关键任务不要只让模型“读一遍”

任务重要的时候，不要只发一句：
帮我总结这份 100 页文档。
更稳的方式，是把任务拆开： 先提取目录和主题； 再按章节提炼要点； 接着追问证据出处； 最后汇总结论和不确定点。
这样做的目的不是把流程弄复杂。它是在把“长上下文压力”拆成几个更可控的步骤。

3. 多答案任务要显式检查遗漏

如果你要模型列清单，比如风险项、待办事项、人物关系、引用来源，最好加一个复查步骤。
可以这样写：
请先列出所有候选项，再逐段检查是否遗漏。
最后输出“可能遗漏的位置”和“不确定项”。
这不是玄学。RULER 的结果已经说明，长上下文里的多答案召回不全，是一个真实问题。

4. RAG 不要迷信“召回越多越好”

很多知识库问答系统喜欢一次召回很多 chunk，觉得多多益善。
但从 RULER 的角度看，这也可能带来更多干扰项。
更稳的做法是提高检索质量，做 rerank，去重，保留出处，并让模型先判断哪些材料相关，再回答。
上下文窗口不要被塞满。要让模型看到该看的东西。

5. 评测模型时，不要只测“找针”

如果你要判断一个长上下文模型适不适合自己的业务，可以参考 RULER 的思路，自己做一套小测试： 检索：能不能从长材料里找出指定事实？ 多跳：能不能追踪跨段落的关系链？ 聚合：能不能统计和归纳分散信息？ 问答：能不能在干扰材料里回答需要理解的问题？ 多答案：能不能一次找全，而不是只找一个？
这些测试不用做得很复杂。
直接用自己的材料设计几组问题，往往比看宣传页上的 128K、1M 更接近真实体验。

6. RULER 也不是终点

RULER 很有价值，但也不能把它神化。
论文自己也提到了一些限制。
第一，RULER 主要报告某个输入长度下的单个指标，没有充分控制关键信息在上下文里的位置。
也就是说，它没有系统展开我们常说的 lost-in-the-middle 问题。信息放在开头、中间、结尾，模型表现可能不一样。
第二，RULER 是合成任务。Variable Tracking、词频聚合这些任务可以作为真实任务的代理，但它们毕竟不等于真实业务里的长文档理解。
第三，论文主要选择了大多数模型在 4K 能做得还不错的任务，用来观察长度增加后的退化。所以不能误读成“模型在 4K 就一定没问题”。
第四，论文没有系统验证 prompt 格式鲁棒性。实际使用模型时，提示词格式有时会明显影响结果。
所以我会把 RULER 看成一把尺子，而不是最终答案。
它最重要的贡献，是把我们的注意力从“这个模型能塞多少 Token”，拉回到“这个模型在长上下文里到底能完成哪些动作”。

写在最后

长上下文当然重要。
读论文、读代码、做知识库、分析会议纪要、处理长文档，都离不开它。
但上下文长度不是一个越大越好的单一数字。它背后其实是一组能力：检索、抗干扰、关系追踪、信息聚合、多答案召回，以及在长材料里继续依赖证据，而不是凭记忆发挥。
如果只是日常聊天，可能不用太纠结这些。
但如果你正在做知识库、Agent、AI Coding、论文阅读、企业内部问答，最好别只测试模型能不能装下资料。还要测试它能不能真的用好资料。
模型能读 1M Token 是能力进步，但怎么组织资料、怎么拆任务、怎么复查遗漏，仍然决定了 AI 在真实工作流里能不能靠谱。
资料来源： 论文 arXiv：https://arxiv.org/abs/2404.06654 代码仓库：https://github.com/NVIDIA/RULER
AI 科普系列的其他文章： 终于有人把“智能体”的概念给我讲明白了！ 终于有人把 RAG 的概念讲清楚了 终于有人把“大语言模型”的概念给我讲明白了！ 终于有人把 MCP 的概念给我讲明白了
创作不易，如果文章对你有帮助，欢迎点赞、喜欢和分享给身边需要的朋友。
欢迎关注我的公众号，后续会继续分享 AI 工具、实践经验，以及一些尽量客观理性的 AI 观察。